1. Technical Field
This invention relates to the establishment of a tunnel entrance for packets crossing the border between a first network operating in accordance with a first transmission protocol and having network addresses in accordance with a first addressing convention, herein referred to as first type addresses, and a second network operating in accordance with a second transmission protocol and having network addresses in accordance with a second addressing convention, herein referred to as second type addresses, and relates particularly, but not exclusively, to communication between hosts in respective Internet Protocol version 6 (IPv6) domains separated by an Internet Protocol version 4 (IPv4) domain.
Herein, the terms packet and message are used interchangeably and have the same meaning, and the term Internet domain is used as a specific example of a network.
2. Related Art
In Internet technology, it had become apparent that the initial transport protocol, IPv4, needed to be enhanced, principally to increase the available address space and add a hierarchical address structure. The result was IPv6 which has a simplified header format compared with IPv4, but which uses 128 bit addresses as compared with 32 bit addresses used in IPv4.
Readers wishing to have an overview of this general area might like to access a list of Internet-Drafts, which are working documents of the IETF, at http://www.ietf.org/1id-abstracts.txt, and a particularly relevant document is “A Guide to the Introduction of IPv6 in the IPv4 World”<draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt>, also referred to as “Guide to IPv6 Transition”.
As mentioned, the present invention relates to tunnelling. Known tunnelling techniques are of two types: configured and automatic.
A configured tunnel is created by manual configuration of a tunnelling interface between an IPv6 domain and an IPv4 domain such that all packets received from the IPv6 domain are encapsulated in IPv4 packets addressed to a specific tunnel end point, i.e. the tunnelling interface between the IPv4 domain and the remote IPv6 domain containing the destination IPv6 host.
An automatic tunnel on the other hand does not need manual configuration: the tunnel end points are automatically determined. Several automatic tunnelling mechanisms are currently in development within the IETF, these being known in the art as, 6over4, 6to4, Dynamic Tunnelling, and Tunnel Broker.
For more detailed information on 6over4 the reader can obtain from the IETF, the document known as RFC2829, or any variant thereof, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, by B. Carpenter and C. Jung, March 1999.
For more detailed information on 6to4 the reader can obtain from the IETF, the document known as draft-ietf-ngtrans-6to4-02.txt, or any variant thereof, “Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels”, by B. Carpenter and K. Moore.
For more detailed information on Dynamic Tunnelling the reader can obtain from the IETF, the document known as draft-ietf-ngtrans-dti-00.txt.
For more detailed information on Tunnel Broker the reader can obtain from the IETF, the document known as draft-ietf-ngtrans-broker-00.txt.
These known automatic tunnelling mechanisms use a variety of techniques to enable the tunnel to be automatically established:
ξ 6over4 Multicast
ξ 6to4 Special IPv6 address in which the top level aggregator (TLA) contains an identifier for the 6to4 tunnelling mechanism, and the next level aggregator (NLA) contains the IPv4 address of the tunnel end point
ξ Dynamic Tunnelling via DNS
ξ Tunnel Broker www based tool